From mcdermot@eagle.aud.alcatel.com  Mon Oct 31 13:16:01 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r22Cz-00012MC; Mon, 31 Oct 94 13:15 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA13995; Mon, 31 Oct 94 13:14:46 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA00711; Mon, 31 Oct 94 13:15:46 CST
Date: Mon, 31 Oct 94 13:15:46 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9410311915.AA00711@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:70] HF Modulation


> Many of my friends ask me why I hate CLOVER.  I tell them that I don't
> but feel for that amount of money, hams should get more BPS for their
> buck.  Hear's the reason.  CLOVER uses 4 parallel tones to get 800-900
> BPS.  The commercial/military modems use 39 tones to get 2400 BPS with
> the 40th tone as an unmodulated/standard modulated pilot/doppler tone.
> I believe that some where between 4 and 40 tones hams (those of you who
> are much smarter than I) can come up with a modem for HF that will be
> very robust and produce 1200-2400 (and maybe more) BPS in a BW that is
> less than the commercial/military modem.
> 
> If the guys who will do the actual programming "max-out" the soundcard
> and produce a robust, 2400 BPS (100 baud or less) HF modem and can apply
> the the same principle to a V/UHF modem and get 9600/19.2K BPS, ham
> radio will have greatly benefited.  If they can produce only 1200 BPS on
> HF and 4800 or 9600 on V/UHF, thats Ok too...just max-out the sound
> cards capability.  By then, perhaps better sound cards and/or other
> devices will be on the market that will let us go higher.
 ...
> Walt@home (dba k5yfw)
> 


	Perhaps I'm missing a point here, or someone can correct me if
I'm wrong ... I thought that there was a 500 hz bandwidth limit within the
CW/RTTY segments on HF - and that one of the reasons that CLOVER is only
4 tones (carriers) is so that it would fit within that BW limit.


							- Tom, N5EG
From FORRERJ@frl.orst.edu Tue Nov 01 10:58:32 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r2MXT-0001LLC; Tue, 1 Nov 94 10:58 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA07397 for <hfsig@tapr.org>; Tue, 1 Nov 1994 01:36:45 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 1 Nov 94 9:57:14 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Nov 94 9:57:05 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 1 Nov 1994 09:56:58 PST8PDT
Subject:       Re: [HFSIG:72] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6B8BA2E5D76@frl.orst.edu>

Hi Tom,

Re: 500 Hz BW limitation - our digital activies on HF are regulated by 
Part 97 of the FCC regulations: it says that we can use up to 300 baud or 
1000 Hz shift. 

The 500 Hz BW issue has been brought up recently by parts of the digital 
community that has actually gone so far as to file petition requesting 
such BW for for semi-automatic operations (mainly APlink usage). Except for 
the Clover modulation scheme, none of the *presently available* equipment 
is capable of staying within 500 Hz. This is due to the "fuzzy" definition 
of how folks measure emitted BW. If you do like the Clover folks and 
specify BW at say 50 dB down from the main lobe, then just about everyone 
else uses in excess of 800 Hz. So, asking for 500 Hz BW right now with what 
is on the market right now, Clover is the only one that will comply for 
APlink usage. Does folks realize what this petition means?

Thanks for bringing up this point - hopefully we will show that with the 
right kind of technology, our present BW allocation can go a long way 
towards high speed HF digital - there is no need for additional regulations. 


73's

Johan
From jbloom@arrl.org Tue Nov 01 12:17:06 1994
Return-Path: <jbloom@arrl.org>
Received: from uu7.psi.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r2NlV-0000hUC; Tue, 1 Nov 94 12:17 CST
Received: from mgate.arrl.org by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
        id AA23772 for hfsig@tapr.org; Tue, 1 Nov 94 13:17:24 -0500
Received: from arrl.org by mgate.arrl.org with smtp
	(Smail3.1.28.1 #6) id m0r2Njf-000B9iC; Tue, 1 Nov 94 13:15 EST
Received: by arrl.org with Microsoft Mail
	id <2EB68625@arrl.org>; Tue, 01 Nov 94 13:17:09 EST
From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:73] Re: HF Modulation
Date: Tue, 01 Nov 94 13:15:00 EST
Message-Id: <2EB68625@arrl.org>
Encoding: 35 TEXT
X-Mailer: Microsoft Mail V3.0


>The 500 Hz BW issue has been brought up recently by parts of the digital
>community that has actually gone so far as to file petition requesting
>such BW for for semi-automatic operations (mainly APlink usage). Except for 

>the Clover modulation scheme, none of the *presently available* equipment
>is capable of staying within 500 Hz. This is due to the "fuzzy" definition
>of how folks measure emitted BW. If you do like the Clover folks and
>specify BW at say 50 dB down from the main lobe, then just about everyone
>else uses in excess of 800 Hz. So, asking for 500 Hz BW right now with what 

>is on the market right now, Clover is the only one that will comply for
>APlink usage. Does folks realize what this petition means?

The specification of occupied bandwidth is in Sec 2.202 of FCC Rules and 
Regulations (Appendix 10 in ARRL's FCC Rule Book). It is set by the points 
in the spectrum where the sum of the power at frequencies above and below 
those points is 0.5% of the total power. (Interestingly, there is a 
qualification of this rule for multi-channel frequency division systems, 
which may have difficulty meeting such a definition.) In any case, 170-Hz 
shift, 100-baud transmissions (AMTOR or RTTY) with proper key shaping fall 
within a 500-Hz bandwidth by the above definition. The 500-Hz bandwidth 
limitation does *not* rule out the use of modes other than Clover!

That said, the FCC's definition of bandwidth is probably not the one we want 
to key on. The reason Clover strives to maintain almost all of its energy 
within a 500-Hz bandwidth is not for legal requirements, rather it's because 
doing so means you can actually use 500-Hz channelization. Try running a 
mediocre AMTOR link when there's another AMTOR station 500-Hz away that is 
40 dB above the station you're trying to copy. That adjacent-channel station 
may be "occupying" a 500-Hz bandwidth, but you'll still find your copy 
corrupted by his "insignificant" sidebands only 30 dB or so down from his 
carrier.

 -- Jon, KE3Z
From FORRERJ@frl.orst.edu Tue Nov 01 13:37:36 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r2P1S-0001KzC; Tue, 1 Nov 94 13:37 CST
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Nov 94 11:37:04 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 1 Nov 1994 11:36:56 PST8PDT
Subject:       HF Channel simulator
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6BB64D6637A@frl.orst.edu>

Greetings,

For those interested in the channel simulator, do yourself a favour and 
also obtain the Watterson et al. paper:

Clack C. Watterson, John R. Jurosheck, and William D. Bensema: 
"Experimental Confirmation of an HF Channel Model". IEEE Trans. on Comm. 
Tech. Vol COM-18(6) December 1970.

It appears quite doable - perhaps we should form a working group of those 
that wish to actively participate in coding this model? Please e-mail me 
directly. Does this sound reasonable? We will post our progress (if any).


73's

Johan
From FORRERJ@frl.orst.edu Tue Nov 08 11:47:55 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r4ue7-0001GPC; Tue, 8 Nov 94 11:47 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA10584 for <HFSIG@tapr.org>; Tue, 8 Nov 1994 02:26:48 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 8 Nov 94 9:47:32 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 8 Nov 94 9:47:30 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 8 Nov 1994 09:47:30 PST8PDT
Subject:       HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <761961E4752@frl.orst.edu>

Hi Folks,

Quiet on the homefront? 

A few general comments: I have suggested some reading materials -
If you have do not have access to these, perhaps I can help make
photocopies - please e-mail me directly. These papers are quite
old, though very appropriate. Unfortunately they also are quite
mathematically inclined - however, don't be intimidated by a bit
of algebra. If you are not interested in all the gory details,
just make sure you understand the premise and note the
conclusions. Some things take a while to sink in and as one
develop your grasp of the subject, it becomes clearer later.

The insight that these papers attempt to provide is: given some
model of the "channel", how does different modulation schemes
stack up? Typically various forms of OOK (on-off keying), FSK,
and PSK, are considered against white (additive Gaussian white)
noise - where it is shown that: for the same amount of emitted
energy,  phase modulation schemes have slightly lower error
rates. Now keep in mind that some rather important assumptions
are made, i.e. that we have the RX and TX in perfect sync as far
as carrier phase and symbol sync is concerned. Well, what happens
if that is not the case and what if the channel model includes phase jitter? 
We see that performance drops rather dramatically. This is where the issue 
of robustness comes in and where we see that noncoherent FSK actually does 
very well - it requires little or no assumptions! However, just keep those
theoretical rankings in mind as the limits of performance under
ideal conditions.

Well, then why don't we just go ahead and use noncoherent FSK?
Lets say we are aiming for 1200 bps (uncoded).
Theoretically, this would require a minimum of 1200 Hz shift, and need at
least an additional 1200 Hz to accommodate the modulation
envelope - total about 2400 Hz. Two major problems: that's a lot
of bandwidth for HF, second, such short bit times would be a
disaster on HF with multipath and the other kinds of channel
anomalies. OK - so what else can we do? We have to make a
tradeoff: lower robustness for more bandwidth efficiency. That is
why some of those papers looked at those complex modulated schemes, i.e. 
QAM etc.. and their performance under non-ideal conditions. The Foschini
paper surprisingly shows that QAM does better than expected -
which is great news.

The other papers is about carrier and data recovery using phase
lock loops - more about this later. 

One last note: the 2-3 dB loss in performance associated with a
bandwidth-efficient modulation scheme, may be offset with coding gain 
achieved by coding theory, i.e. trellis modulation/viterbi demodulation 
etc. This sophistication, unfortunately, adds greater complexity to the 
implementation. The DSP/host algorithms are necessarily going to be closely
coupled and this alone hints that an involved system is in your
future.

A bit of progress with the PSK modem - the modulator is working
nicely and soon I'll be testing with two sound cards back-to-
back. This setup, however, is very experimental and is, for me at
least, a way of learning how all these intricate algorithms work
together. 

I have collected and studied some further materials on the channel 
simulator, enough to see that it is quite doable. More about that later.

I would like to hear any further thoughts or suggestions from your side. 
Please let us hear from you. 

73's

Johan
From FORRERJ@frl.orst.edu Tue Nov 08 12:17:07 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r4v6O-000162C; Tue, 8 Nov 94 12:17 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id CAA10839 for <HFSIG@tapr.org>; Tue, 8 Nov 1994 02:56:00 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 8 Nov 94 10:16:44 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 8 Nov 94 10:16:16 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 8 Nov 1994 10:16:12 PST8PDT
Subject:       SOUNDWAVE TOOLS
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <76210DD4A6A@frl.orst.edu>

>Hi Johan,
>
>I just received my Soundwave card yesterday. It sure is fun having a new
>toy! You once mentioned (I think) that there is a freeware assembler for
>the DSP floating around out there. Can you tell me where? Also, is there
>any board-level technical documentation (i.e. block diagram, memory map,
>etc.) available to developers? I can get data books on the individual
>chips from their respective vendors, but it would be nice to know how they
>go together! 
>
>Maybe you should post your reply to the net.
>
>    73s
>
>    Hugh

Hi Hugh,

OK - now the fun really starts!

First get hold of the August 1994 QEX. I have described the chip set, 
memory layout, and mayor PC-DSP programming issues in some detail in 
that article. 

You also *must* get the AD1848 data sheet for sure, and the 21xx user's 
guide for sure. That will help you with the 2115's architecture and 
programmer's model.

The most recent PD toolkit for the sound card is available from ftp.ucsd.edu 
in /hamradio/packet/tcpip/incoming/psatool1.zip, also at ftp.cs.buffalo. 
You will also find some further example applications code for the QEX 
article(s) there too. Also check out my port of the W9GR DSP for the 
sound card - I recently uploaded that.

I wonder if you have obtained HB9JNX's 9600 baud G3RUH modem for the 
sound card? If so, perhaps you could make that available too? That may be 
and interesting application to explore.

I would also suggest browsing Analog Devices ftp site: ftp.analog.com 
(137.71.23.11) for all sorts of useful bits of hardware/software 
information and code examples. 

Keep in mind that there are *real* ADI software tools available - I 
recently got their assembler/linker/simulator and C-compiler at very 
reasonable cost during a "special" offer deal.

This will keep you busy for a while, but let me know if you need further 
assistance.

73's

Johan
From mcdermot@eagle.aud.alcatel.com  Tue Nov 08 15:06:22 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r4xkB-0001gAC; Tue, 8 Nov 94 15:06 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA06493; Tue, 8 Nov 94 15:05:56 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA06303; Tue, 8 Nov 94 15:05:56 CST
Date: Tue, 8 Nov 94 15:05:56 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411082105.AA06303@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:76] HF Modulation

> Hi Folks,
> 
> Quiet on the homefront? 
> 
> A few general comments: I have suggested some reading materials -
> If you have do not have access to these, perhaps I can help make
> photocopies - please e-mail me directly. These papers are quite
> old, though very appropriate. Unfortunately they also are quite
> mathematically inclined - however, don't be intimidated by a bit
> of algebra. If you are not interested in all the gory details,
> just make sure you understand the premise and note the
> conclusions. Some things take a while to sink in and as one
> develop your grasp of the subject, it becomes clearer later.

 ....

> I would like to hear any further thoughts or suggestions from your side. 
> Please let us hear from you. 
> 
> 73's
> 
> Johan
> 

	Johan, I acquired a copy of "Experimental Confirmation of an HF
Channel Model" IEEE ComTech, COM-18 No. 6.  The channel model proposed seems
straight-forward, however the derivation of the baseband channel modulation
functions, Gi(t) is anything but straight-forward, and certainly a little
bit beyond algebra.

	Mapping of the parameters from tables I and II into deterministic
formulas has so far eluded me.  Have you looked into this?  My guess would be
to choose random processes with gaussian distributions to fit the observed
data.  However, I see the problem as one of mapping random PHASE of G(t)
into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond my
mathematical background at present.  Do you know of a simple algorithm that
generates gaussian-distributed random numbers?

	Additionally, the author states that the fading of each individual
propagation component is represented by a Rayleigh distribution.  I think the
formula for that is fairly tractable.  I would assume that a random-number
generator that creates a Rayleigh distribution applied to the magnitude of
each Gi(t) would be used here.  I found a simple formula from some microwave
radio stuff done here about 10 years ago (where a Rayleigh path is the
standard assumption) but it is not clear what the coefficients should be
after looking at Tables I and II.

	The two data points were taken at 9.26 Mhz, and 5.86 Mhz.  Would 
the data points taken from a higher frequency (14, 21, 28 Mhz) be 
significantly different (with a potentially longer path, one might think so).

	The article is definitely interesting, but after two complete read
throughs, it will still require significant study to grasp.

							- Tom, N5EG
From Glen_Worstell@notes.seagate.com Tue Nov 08 17:47:24 1994
Return-Path: <seagate!notes.seagate.com!Glen_Worstell@netcom.com>
Received: from netcomsv.netcom.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r50G0-0001lBC; Tue, 8 Nov 94 17:47 CST
Received: from seagate.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
	id PAA24175; Tue, 8 Nov 1994 15:39:23 -0800
Received:  by notes.seagate.com (UUPC/extended 1.11q);
           Tue, 08 Nov 1994 16:19:03 EST
Date:         Tue Nov 08 16:19:03 1994
From: "Glen Worstell" <Glen_Worstell@notes.seagate.com>
Sender: Gateway <gateway@notes.seagate.com>
Message-ID: <2ebfeb48.seagate@notes.seagate.com>
Organization: Seagate Technology
Reply-To: "Glen Worstell" <Glen_Worstell@notes.seagate.com>
To: hfsig@tapr.org
Subject:      Re: [HFSIG:78] Re: HF Modulation

> Do you know of a simple algorithm that generates
gaussian-distributed random numbers?
 
Two answers:
1) use the "randn" function in Matlab.
2) From "Communication Formulas and Algorithms", C. Rorabaugh:
 
a)  Generate a psuedorandom floating point number U1 greater
  than 0 and <= 1.0
b)  Generate another one, U2.
c)  G1=cos(U2)*sqrt(-2*ln(U1)*sigma*sigma)
d)  G2=sin(U2)*sqrt(-2*ln(U1)*sigma*sigma)
 
G1 and G2 will be independent zero-mean gaussian "random
numbers" with standard deviation of sigma.
 
The book gives another method which is a bit faster as it
does not use trig functions.
 
Important:  you must have a good random number generator
routine to start with.  some unix systems have 16 bit generators
which are not very good.  Also, for this sort of work the gaussian
generator must have a good "crest factor".  That is, the percent
of numbers exceeding, say, 6 sigma must be in the ballpark of
the predicted amount.  This will not happen if the quality of the
random number generator is not good (for example, not enuf
bits).
 
I used this method in a disk channel simulator, with good
results.  Disk drives are a lot like communication channels!
 
Cheers,
Glen Worstell, KG0T
--
Glen Worstell -- Glen_Worstell@notes.seagate.com
-------------------------------------------------------------------------
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster@notes.seagate.com
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  
-------------------------------------------------------------------------
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Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 8 Nov 94 16:07:22 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 8 Nov 1994 16:07:13 PST8PDT
Subject:       Re: [HFSIG:78] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <767EB0E2676@frl.orst.edu>


>> Hi Folks,
>> 
>> Quiet on the homefront? 
>> 
>> A few general comments: I have suggested some reading materials -
>> If you have do not have access to these, perhaps I can help make
>> photocopies - please e-mail me directly. These papers are quite
>> old, though very appropriate. Unfortunately they also are quite
>> mathematically inclined - however, don't be intimidated by a bit
>> of algebra. If you are not interested in all the gory details,
>> just make sure you understand the premise and note the
>> conclusions. Some things take a while to sink in and as one
>> develop your grasp of the subject, it becomes clearer later.
>
> ....
>
>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 
>> 
>> 73's
>> 
>>Johan
>> 

>    Johan, I acquired a copy of "Experimental Confirmation of an HF
>Channel Model" IEEE ComTech, COM-18 No. 6.  The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra.


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'm a 
mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 

Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic
>formulas has so far eluded me.  Have you looked into this?  My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data.  However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present.  Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers?


I think you have a good grasp of what is required. What might help 
further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 
list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 

About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.:

WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
WGN_imag = ........................sin............

where: std is the std. dev. of GN,
       ran1, ran2 is uniformly distributed between 0,1
        
Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute.

Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK?

>
>    Additionally, the author states that the fading of each individual
>propagation component is represented by a Rayleigh distribution.  I think 
>the formula for that is fairly tractable.  I would assume that a random-


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2.

............< > 

>    The two data points were taken at 9.26 Mhz, and 5.86 Mhz.  Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so).
>


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF.   


>    The article is definitely interesting, but after two complete read
>throughs, it will still require significant study to grasp.
>
>                            - Tom, N5EG


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 

Keep us posted on your progress.

Johan, KC7WW
From esilbaug@afit.af.mil Tue Nov 08 20:06:24 1994
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r52QW-0001lYC; Tue, 8 Nov 94 20:06 CST
Received: from owl.afit.af.mil by stealth.afit.af.mil with SMTP id AA11090
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Tue, 8 Nov 1994 21:06:15 -0500
Date: Tue, 8 Nov 1994 21:06:15 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199411090206.AA11090@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: RE: HF Channel Simulator
Cc: esilbaug@afit.af.mil


Those of you who have been discussing HF channel simulation may
be interested in the following paper.  I ran across it while doing
research on an unrelated topic.

   L. Ehrman, L.B. Bates, J.F. Eschile, J.M. Kates, "Realtime
   Software Simulation of the HF Radio Channel" IEEE Trans. on
   Communications, August 1982, p.1809

It contains an overview of the theoretical HF channel model and
details on how it was implemented on a signal processor.  They
used special purpose hardware but today's DSP chips should be up
to the task.

For those of you interested in how various modulation methods
hold up under interference, check out this paper.

   O.A.H. Shabsigh, "On the Effects of CW Interference on MSK
   Signal Reception" IEEE Trans. on Communications, August
   1982, p.1925

Wouldn't want our fancy new demodulator to crumble when some lid
starts doing 5 WPM on top of our signal would we.

I have enjoyed lurking on this SIG for a few weeks.  Lots of
good ideas floating around (now, if we could only catch them).
By the way, I'm currently pursuing an MSEE in communications
and radar systems.  I got into amateur radio to put some of this
theory into practice.  Later!

Eric

    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
From Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil Tue Nov 08 23:54:26 1994
Return-Path: <Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil>
Received: from opal.spawar.navy.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r55z4-0001lUC; Tue, 8 Nov 94 23:54 CST
Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (4.1/SMI-4.1)
	id AA15566; Wed, 9 Nov 94 00:52:20 EST
Received: from cc:Mail by smtp-gw.spawar.navy.mil
	id AA784371227; Wed, 09 Nov 94 00:51:46 EST
Date: Wed, 09 Nov 94 00:51:46 EST
From: Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil
Encoding: 111 Text
Message-Id: <9410097843.AA784371227@smtp-gw.spawar.navy.mil>
To: hfsig@tapr.org
Subject: Message not deliverable

>> Hi Folks,
>> 
>> Quiet on the homefront? 
>> 
>> A few general comments: I have suggested some reading materials -
>> If you have do not have access to these, perhaps I can help make
>> photocopies - please e-mail me directly. These papers are quite
>> old, though very appropriate. Unfortunately they also are quite
>> mathematically inclined - however, don't be intimidated by a bit
>> of algebra. If you are not interested in all the gory details,
>> just make sure you understand the premise and note the
>> conclusions. Some things take a while to sink in and as one
>> develop your grasp of the subject, it becomes clearer later.
>
> ....
>
>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 
>> 
>> 73's
>> 
>>Johan
>> 

>    Johan, I acquired a copy of "Experimental Confirmation of an HF
>Channel Model" IEEE ComTech, COM-18 No. 6.  The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra.


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'm a 
mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 

Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic
>formulas has so far eluded me.  Have you looked into this?  My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data.  However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present.  Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers?


I think you have a good grasp of what is required. What might help 
further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 
list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 

About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.:

WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
WGN_imag = ........................sin............

where: std is the std. dev. of GN,
       ran1, ran2 is uniformly distributed between 0,1
        
Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute.

Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK?

>
>    Additionally, the author states that the fading of each individual
>propagation component is represented by a Rayleigh distribution.  I think 
>the formula for that is fairly tractable.  I would assume that a random-


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2.

...........< > 

>    The two data points were taken at 9.26 Mhz, and 5.86 Mhz.  Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so).
>


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF.   


>    The article is definitely interesting, but after two complete read
>throughs, it will still require significant study to grasp.
>
>                            - Tom, N5EG


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 

Keep us posted on your progress.

Johan, KC7WW

From Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil Wed Nov 09 00:01:38 1994
Return-Path: <Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil>
Received: from opal.spawar.navy.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r565r-0001isC; Wed, 9 Nov 94 00:01 CST
Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (4.1/SMI-4.1)
	id AA15615; Wed, 9 Nov 94 00:59:21 EST
Received: from cc:Mail by smtp-gw.spawar.navy.mil
	id AA784371667; Wed, 09 Nov 94 01:00:13 EST
Date: Wed, 09 Nov 94 01:00:13 EST
From: Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil
Encoding: 112 Text
Message-Id: <9410097843.AA784371667@smtp-gw.spawar.navy.mil>
To: hfsig@tapr.org
Subject: Message not deliverable

>> Hi Folks,
>> 
>> Quiet on the homefront? 
>> 
>> A few general comments: I have suggested some reading materials -
>> If you have do not have access to these, perhaps I can help make
>> photocopies - please e-mail me directly. These papers are quite
>> old, though very appropriate. Unfortunately they also are quite
>> mathematically inclined - however, don't be intimidated by a bit
>> of algebra. If you are not interested in all the gory details,
>> just make sure you understand the premise and note the
>> conclusions. Some things take a while to sink in and as one
>> develop your grasp of the subject, it becomes clearer later.
>
> ....
>
>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 
>> 
>> 73's
>> 
>>Johan
>> 

>    Johan, I acquired a copy of "Experimental Confirmation of an HF
>Channel Model" IEEE ComTech, COM-18 No. 6.  The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra.


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'm a 
mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 

Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic
>formulas has so far eluded me.  Have you looked into this?  My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data.  However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present.  Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers?


I think you have a good grasp of what is required. What might help 
further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 
list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 

About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.:

WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
WGN_imag = ........................sin............

where: std is the std. dev. of GN,
       ran1, ran2 is uniformly distributed between 0,1
        
Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute.

Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK?

>
>    Additionally, the author states that the fading of each individual
>propagation component is represented by a Rayleigh distribution.  I think 
>the formula for that is fairly tractable.  I would assume that a random-


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2.

..........< > 

>    The two data points were taken at 9.26 Mhz, and 5.86 Mhz.  Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so).
>


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF.   


>    The article is definitely interesting, but after two complete read
>throughs, it will still require significant study to grasp.
>
>                            - Tom, N5EG


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 

Keep us posted on your progress.

Johan, KC7WW


From Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil Wed Nov 09 05:19:46 1994
Return-Path: <Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil>
Received: from opal.spawar.navy.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5B1l-0001hRC; Wed, 9 Nov 94 05:17 CST
Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (4.1/SMI-4.1)
	id AA17277; Wed, 9 Nov 94 06:09:14 EST
Received: from cc:Mail by smtp-gw.spawar.navy.mil
	id AA784390258; Wed, 09 Nov 94 06:10:30 EST
Date: Wed, 09 Nov 94 06:10:30 EST
From: Administrator_at_SPAWAR-MC4@smtp-gw.spawar.navy.mil
Encoding: 113 Text
Message-Id: <9410097843.AA784390258@smtp-gw.spawar.navy.mil>
To: hfsig@tapr.org
Subject: Message not deliverable

>> Hi Folks,
>> 
>> Quiet on the homefront? 
>> 
>> A few general comments: I have suggested some reading materials -
>> If you have do not have access to these, perhaps I can help make
>> photocopies - please e-mail me directly. These papers are quite
>> old, though very appropriate. Unfortunately they also are quite
>> mathematically inclined - however, don't be intimidated by a bit
>> of algebra. If you are not interested in all the gory details,
>> just make sure you understand the premise and note the
>> conclusions. Some things take a while to sink in and as one
>> develop your grasp of the subject, it becomes clearer later.
>
> ....
>
>> I would like to hear any further thoughts or suggestions from your side. 
>> Please let us hear from you. 
>> 
>> 73's
>> 
>>Johan
>> 

>    Johan, I acquired a copy of "Experimental Confirmation of an HF
>Channel Model" IEEE ComTech, COM-18 No. 6.  The channel model proposed 
>seems straight-forward, however the derivation of the baseband channel 
>modulation functions, Gi(t) is anything but straight-forward, and certainly 
>a little bit beyond algebra.


Outstanding Tom! ..... agree that nothing about this is that simple - but 
folks should also not feel intimidated by scolarly papers. I'm a 
mediocre mathematician at best with self-taught interests in DSP and COMM 
theory - programming is what I like best. 

Lets explore your questions and perhaps we can unravel this thing 
together ..... 


>>Mapping of the parameters from tables I and II into deterministic
>formulas has so far eluded me.  Have you looked into this?  My guess would 
>be to choose random processes with gaussian distributions to fit the 
>observed data.  However, I see the problem as one of mapping random PHASE 
>of G(t) into a gaussian-shaped FREQUENCY shift of the signal, a bit beyond 
> my mathematical background at present.  Do you know of a simple algorithm 
>that generates gaussian-distributed random numbers?


I think you have a good grasp of what is required. What might help 
further now is to get CCIR Report 549-2 - look at p.60-62 for a fuller 
description of the Gaussian-scatter model and formulae. Tables I and II of 
the Watterson paper is very complete and you probably don't want to try and 
emulate that in its entirety. If you further obtain CCIR 520- 1, they 
list all the parameters of interest for "Good", "Moderate", "Poor", and 
"Flutter fading" that may be put to good use in the model. 

About the random Gaussian number generator, lets keep in 
mind that the baseband signal is complex, thus you need to generate a 
complex random number too, i.e.:

WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
WGN_imag = ........................sin............

where: std is the std. dev. of GN,
       ran1, ran2 is uniformly distributed between 0,1
        
Then you have to think a little about how to balance the summation node, 
i.e. the amount of power that each tap is going to contribute.

Also think a bit about what you are going to do about the different 
sample rates involved at each tap, i.e. they will be somewhat different 
thus you would have to include interpolating filters before mixing in the 
doppler signal. OK?

>
>    Additionally, the author states that the fading of each individual
>propagation component is represented by a Rayleigh distribution.  I think 
>the formula for that is fairly tractable.  I would assume that a random-


Yes, that is described in the references of CCIR 549-2 and also in some 
detail on p.62 of 549-2.

.........< > 

>    The two data points were taken at 9.26 Mhz, and 5.86 Mhz.  Would 
>the data points taken from a higher frequency (14, 21, 28 Mhz) be 
>significantly different (with a potentially longer path, one might think 
>so).
>


Certainly - different frequencies will behave differently - from 
what I have read on this subject, multipath, is strongly dependant 
on the MUF.   


>    The article is definitely interesting, but after two complete read
>throughs, it will still require significant study to grasp.
>
>                            - Tom, N5EG


Appreciate your feedback. I would not have known anything on this topic 
were it not for generous help from others (I still am struggling with this 
too). 

Keep us posted on your progress.

Johan, KC7WW



From mcdermot@eagle.aud.alcatel.com  Wed Nov 09 07:54:13 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5DTT-0000LAC; Wed, 9 Nov 94 07:54 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA25422; Wed, 9 Nov 94 07:53:44 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA06918; Wed, 9 Nov 94 07:53:43 CST
Date: Wed, 9 Nov 94 07:53:43 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411091353.AA06918@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:80] Re: HF Modulation


> About the random Gaussian number generator, lets keep in 
> mind that the baseband signal is complex, thus you need to generate a 
> complex random number too, i.e.:
> 
> WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
> WGN_imag = ........................sin............
> 
> where: std is the std. dev. of GN,
>        ran1, ran2 is uniformly distributed between 0,1
>         
> Johan, KC7WW
> 


	Johan:  the author states that the phase is uniformly distributed.
>From this one would guess that the uniform phase results in gaussian 
frequency, but I have a hard time believing this, actually (doesn't seem
intuitive).  Given the Rayleigh amplitude distribution, I was assuming
that the two components of Gi(t) would be magnitude and phase, with the
above two (non-complex) random distributions.  Then of course we would do
polar-to-rectangular converstion in order to multiply Gi(t) by the delayed
signal.  My guess is that the tapped delay line only contains the real part
of the input signal, but after multiplication by Gi(t), of course it is then
complex.

> Those of you who have been discussing HF channel simulation may
> be interested in the following paper.  I ran across it while doing
> research on an unrelated topic.
>
>    L. Ehrman, L.B. Bates, J.F. Eschile, J.M. Kates, "Realtime
>    Software Simulation of the HF Radio Channel" IEEE Trans. on
>    Communications, August 1982, p.1809
>
> It contains an overview of the theoretical HF channel model and
> details on how it was implemented on a signal processor.  They
> used special purpose hardware but today's DSP chips should be up
> to the task.
>
> Eric

	Thanks for the reference, Eric!  Nothing like seeing a real
implementation.


							- Tom, N5EG
From jbloom@arrl.org Wed Nov 09 09:28:54 1994
Return-Path: <jbloom@arrl.org>
Received: from uu7.psi.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5Ewo-0000ffC; Wed, 9 Nov 94 09:28 CST
Received: from mgate.arrl.org by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
        id AA05331 for hfsig@tapr.org; Wed, 9 Nov 94 10:27:55 -0500
Received: from arrl.org by mgate.arrl.org with smtp
	(Smail3.1.28.1 #6) id m0r5Etn-000B9jC; Wed, 9 Nov 94 10:25 EST
Received: by arrl.org with Microsoft Mail
	id <2EC0EAFF@arrl.org>; Wed, 09 Nov 94 10:30:07 EST
From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:85] Re: HF Modulation
Date: Wed, 09 Nov 94 10:30:00 EST
Message-Id: <2EC0EAFF@arrl.org>
Encoding: 27 TEXT
X-Mailer: Microsoft Mail V3.0


I just acquired a copy of "Simulation of Communication Systems," by Michel 
C. Jeruchim, Philip Balaban and K. Sam Shanmugan. (1992, Plenum Press, New 
York. ISBN 0-306-43989-1.) If you can find a copy of this (I bought mine, to 
the tune of $110), you'll find more than you ever wanted to know about this 
subject! I've yet to find time to delve into it deeply, but it looks like it 
covers the subject in detail, including providing the mathematical 
background.

>> WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
>> WGN_imag = ........................sin............
>>
>> where: std is the std. dev. of GN,
>>        ran1, ran2 is uniformly distributed between 0,1

Should the trig functions be inside the square root as shown? In the book 
referenced above, (in section 3.11, "Computer Generation of Random Numbers 
and Sequences") the authors give the same equations, without including the 
std, but with the cos and sin terms outside the radical. They call this the 
Box-Muller (umlaut over the u) method, by the way. They also give another 
way of generating a zero-mean, unit-variance Gaussian random variable:

Y = (sum from k=1 to 12) (U(k) - 6.0)

where U(k) is a uniformly distributed random number in the interval [0,1].

 -- Jon, KE3Z
From FORRERJ@frl.orst.edu Wed Nov 09 10:31:22 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5Fvb-0000VrC; Wed, 9 Nov 94 10:31 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA15453 for <hfsig@tapr.org>; Wed, 9 Nov 1994 01:10:14 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 9 Nov 94 8:31:00 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 9 Nov 94 8:30:49 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 9 Nov 1994 08:30:39 PST8PDT
Subject:       Re: [HFSIG:86] Re: HF Modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <7784F8A797F@frl.orst.edu>

Hi folks,

Great contributions! Thanks.



>> WGN_real = std * sqrt (-2*ln(ran1)*cos(2*pi*ran2))
>> WGN_imag = ........................sin............
>>
>> where: std is the std. dev. of GN,
>>        ran1, ran2 is uniformly distributed between 0,1

>Should the trig functions be inside the square root as shown? In the book 
>referenced above, (in section 3.11, "Computer Generation of Random Numbers 
>and Sequences") the authors give the same equations, without including the 
>std, but with the cos and sin terms outside the radical. They call this the 
>Box-Muller (umlaut over the u) method, by the way. They also give another 
>way of generating a zero-mean, unit-variance Gaussian random variable:
>
>Y = (sum from k=1 to 12) (U(k) - 6.0)
>
>where U(k) is a uniformly distributed random number in the interval [0,1].
>
> -- Jon, KE3Z


Jon, you are right - the sqrt should only contain the "ln(ran)" 
term, the sin/cos should be outside.


Johan, KC7WW

 
From gjones@tenet.edu Wed Nov 09 14:42:56 1994
Return-Path: <gjones@tenet.edu>
Received: from Kay-Abernathy.tenet.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5Jr2-00010PC; Wed, 9 Nov 94 14:42 CST
Received: (from gjones@localhost) by Kay-Abernathy.tenet.edu (8.6.9/8.6.9) id OAA15915 for hfsig@tapr.org; Wed, 9 Nov 1994 14:42:49 -0600
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199411092042.OAA15915@Kay-Abernathy.tenet.edu>
Subject: Asst HFSIG Chair/Scribe Needed
To: hfsig@tapr.org (HF SIG mailing)
Date: Wed, 9 Nov 1994 14:42:48 -0600 (CST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 839       

Hi Folks.

Have really enjoyed reading the threads so far.

I have been speaking to Johan and we both feel that the HFSIG needs an asst
chair/scribe.  This position would handle writing up the quarterly report on
the HF SIG for the TAPR PSR.  

While all the threads are kept on file, having the overview report each
quarter in the PSR makes what the HF SIG does a part of the running history
of TAPR and digital communications.  

Also, the part of the Asst Chair is to help Johan organize things as they
need to be done regarding the SIG from time to time when he does not have
time.  As well, the ast chair would be responsible if anything happens to the
chair in the future.  Keeping continuity is very important and the asst
chair position will help with that.

If you think you are interested, contact Johan or me.

Cheers - Greg



From mcdermot@eagle.aud.alcatel.com  Wed Nov 09 16:20:51 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5LNl-0001GzC; Wed, 9 Nov 94 16:20 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA09725; Wed, 9 Nov 94 16:20:23 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA07033; Wed, 9 Nov 94 16:20:21 CST
Date: Wed, 9 Nov 94 16:20:21 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411092220.AA07033@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: CCIR via GOPHER



	For those who may be interested, you can get the complete
listing of CCIR recommendations, and the text (with figures) of some of
them electronically.  The following gopher is available.  I accessed it
recently, and there's a wealth of information on line.  This are the
instructions I downloaded from the README file....

>
> You can access the ITU/TIES information via gopher:
>
>       - use your own gopher client and access to info.itu.ch on port 70
>             or
>       - telnet to gopher.itu.ch on port 2000
>
> Please send any message to helpdesk@itu.ch
>
>                                                 The TIES group
>



A search indicates that the most current version of CCIR 549 is -1, and it is
about sidetone on handset for Shipboard radiotelehpone (there was a
reference to this by one post recently).  Not sure if I copied the number
correctly or not!  The other one, was 520-2, and -2 is the current version.
It is on HF channel simulation.  Unfortunately it is not available 
electronically.

							- Tom, N5EG

From FORRERJ@frl.orst.edu Wed Nov 09 18:05:00 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5N0Z-0001FvC; Wed, 9 Nov 94 18:04 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA19121 for <hfsig@tapr.org>; Wed, 9 Nov 1994 08:43:46 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 9 Nov 94 16:04:33 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 9 Nov 94 16:04:15 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 9 Nov 1994 16:04:07 PST8PDT
Subject:       Re: [HFSIG:89] CCIR via GOPHER
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <77FDE6D00EF@frl.orst.edu>

>    For those who may be interested, you can get the complete
>listing of CCIR recommendations, and the text (with figures) of some of
>them electronically.  The following gopher is available.  I accessed it
>recently, and there's a wealth of information on line.  This are the
>instructions I downloaded from the README file....
>
>>
>> You can access the ITU/TIES information via gopher:
>>
>>       - use your own gopher client and access to info.itu.ch on port 70
>>             or
>>       - telnet to gopher.itu.ch on port 2000
>>
>> Please send any message to helpdesk@itu.ch
>>
>>                                                 The TIES group
>>

>
>
>A search indicates that the most current version of CCIR 549 is -1, and it 
>is about sidetone on handset for Shipboard radiotelehpone (there was a
>reference to this by one post recently).  Not sure if I copied the number
>correctly or not!  The other one, was 520-2, and -2 is the current version.
>It is on HF channel simulation.  Unfortunately it is not available 
>electronically.
>
>
>                            - Tom, N5EG

Hi Tom,

It would be helpful to access the ITU/CCIR sources electronically. I thought 
that it was only available to certain member organizations - but maybe not. 
I'm not sure about the nomenclature - the documents that I have in front of 
me are titled: 

" Report 549-2, HF Ionospheric channel simulators", and 
" Recommendation 520-1, Use of high frequency ionospheric simulators". 

Is it possible that the recommendations and reports are different 
documents? Can anyone help clarify this? 

I read the Ehrman paper - quite interesting and takes you a step closer to 
doing it: there they sampled the input signal at 51.6ksps, filtered it, 
decimated 6:1 before Hilbert-transforming it to produce real and imag. 
components for the tapped delay lines. A fairly understandable description 
follows on how each of the delayed paths are processed to introduce Raleigh 
fading and doppler. Also given are how broad-band and impulse noise are 
treated. On the practical side, seems like they had the randomized Gaussian 
number generator and complex exponential generator as table lookups. The 
question remains whether this could all be done using fixed point or whether 
it needs floating point. It would be real nice if it could all be done on 
the DSP hardware without too much involvement from the host (except for 
configuration and downloading). Would someone like to comment on that?  


Johan, KC7WW
From mcdermot@eagle.aud.alcatel.com  Thu Nov 10 10:45:15 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5ccX-0001zWC; Thu, 10 Nov 94 10:45 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA00655; Thu, 10 Nov 94 10:44:46 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA07689; Thu, 10 Nov 94 10:44:45 CST
Date: Thu, 10 Nov 94 10:44:45 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411101644.AA07689@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Ehrman paper


	I got a copy of the Ehrman paper (IEEE ComTech Vol. 30, No. 8, August
1982), "Real-Time Software Simulation of the HF Radio Channel".  This is a
really good how-to paper.  It clarifies many of the thoughts that were left
somewhat vague by the Watterson paper.  Highly recommended reading.

							- Tom, N5EG
From mcdermot@eagle.aud.alcatel.com  Fri Nov 11 09:43:07 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r5y7z-0000yUC; Fri, 11 Nov 94 09:43 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA01226; Fri, 11 Nov 94 09:42:31 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA08376; Fri, 11 Nov 94 09:42:29 CST
Date: Fri, 11 Nov 94 09:42:29 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411111542.AA08376@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:86] Re: HF Modulation


> Should the trig functions be inside the square root as shown? In the book 
> referenced above, (in section 3.11, "Computer Generation of Random Numbers 
> and Sequences") the authors give the same equations, without including the 
> std, but with the cos and sin terms outside the radical. They call this the 
> Box-Muller (umlaut over the u) method, by the way. They also give another 
> way of generating a zero-mean, unit-variance Gaussian random variable:
> 
> Y = (sum from k=1 to 12) (U(k) - 6.0)
> 
> where U(k) is a uniformly distributed random number in the interval [0,1].
> 
>  -- Jon, KE3Z
> 

	I used EXCEL to generate 500 random numbers using Jon's formula, and
plotted the histogram, both pdf (probability density) and cdf (cummulative
density).  Both the pdf and the cdf look very much like those for gaussian
functions.  The mean is zero (obvious by inspection) and the standard
deviation is 1.0 (not so obvious by inspection?).  Given the lack of needing
a log() or ln() function,  this formula may be easier to generate on a
fixed-point DSP engine.  Ehrman gives a simple formula for a random number
generator if a 32-bit accumulator is available.  Thanks for the info, Jon.

							- Tom, N5EG
From chbrain@dircon.co.uk  Sat Nov 12 05:10:10 1994
Return-Path: <chbrain@dircon.co.uk>
Received: from felix.dircon.co.uk by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r6GLO-0000xZC; Sat, 12 Nov 94 05:10 CST
Received: from aa002.pool.dircon.co.uk by felix.dircon.co.uk with SMTP id AA04501
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 12 Nov 1994 11:08:03 GMT
Date: Sat, 12 Nov 1994 11:08:03 GMT
Message-Id: <199411121108.AA04501@felix.dircon.co.uk>
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.3b4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Bandwidth

I just thought you might like to know what the U.K licence says about bandwidth.

" The bandwidths of emmissions should be such as to ensure the most
efficient utilisation of the spectrum; in general this requires that
bandwidths be kept at the lowest values which technology and the nature of
the service permit. Where bandwidth-expansion techniques are used, the
minimum spectral power density consistent with efficient spectrum
utilisation should be employed."

This I take to mean, is that there is nothing precluding the use of voice
bandwidth data modems on H.F.

Just got my QEX interesting article Johan.

Regards Charles
 ------------------------------
 | Charles Brain (G4GUO)       |
 | Chelmsford, Essex.          |
 | E-mail chbrain@dircon.co.uk |
 | POTS +44 (0)1245 353221     |
 | FAX  +44 (0)1245 275448     |
 -------------------------------

From mcdermot@eagle.aud.alcatel.com  Mon Nov 14 08:10:52 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r727M-0000WIC; Mon, 14 Nov 94 08:10 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA16058; Mon, 14 Nov 94 08:09:34 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA12712; Mon, 14 Nov 94 08:10:28 CST
Date: Mon, 14 Nov 94 08:10:28 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411141410.AA12712@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Channel simulator math


Johan:

	I spent some time reviewing the Ehrman article, and this is my
understanding of the math involved:

	The input is real-valued, but a pseudo-imaginary stream is generated
via a hilbert transform (wideband 90-degree phase shift).  I found a suitable
program for generating coefficients in Burrus & Parks, "Digital Filter Design"
but do not have access to the reference [7, Rabiner] where the efficiency can
be doubled by using an odd number of taps.  Interestingly, an even number of
taps generates a high-pass transform, an odd number of taps must generate a
band-pass transform [B&P].

	Two independent gaussian-distributed random variables modulate the
I,Q components of the vector modulator for each tap.  The random numbers are
filtered by a low pass filter with appropriate time constant.  I am guessing
that a random number that is low pass filtered still has the same random 
distribution statistics as before filtering (except for frequency of course),
this appears to be Ehrman's assumption.

	The Doppler shift is done by a vector modulator with the variable
being a constant-rotating phase shift, but with no random component.  The
rotating phase generates the + or - doppler freqency offset.  The gaussian
frequency doppler spread is caused by the first modulator (in the previous
paragraph) since it had to contribute random phase changes.

	Does this agree with your interpretation?

	Johan, I very much appreciate the references to the various articles,
as they speed up considerably finding and understanding the material!  Trying
to find all the relevant articles is slow and laborious, and that's one of
the good things about the newsgroup - getting those important references
found.  I did acquire a copy of both CCIR reports/recommendations you
suggested, but have not read them yet.

							- Tom, N5EG
From FORRERJ@frl.orst.edu Mon Nov 14 10:34:05 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r74LE-0001KYC; Mon, 14 Nov 94 10:33 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA07160 for <hfsig@tapr.org>; Mon, 14 Nov 1994 01:11:22 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 14 Nov 94 8:32:20 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 14 Nov 94 8:32:18 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 14 Nov 1994 08:32:14 PST8PDT
Subject:       Re: [HFSIG:94] Channel simulator math
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <7F0595A4D2D@frl.orst.edu>

>Johan:
>
>    I spent some time reviewing the Ehrman article, and this is my
>understanding of the math involved:
>
>    The input is real-valued, but a pseudo-imaginary stream is generated
>via a hilbert transform (wideband 90-degree phase shift).  I found a 
>suitable program for generating coefficients in Burrus & Parks, "Digital 
>Filter Design" but do not have access to the reference [7, Rabiner] where 
>the efficiency can be doubled by using an odd number of taps.  
>Interestingly, an even number of taps generates a high-pass transform, an 
>odd number of taps must generate a band-pass transform [B&P].



Yes, an analytical signal is formed, though of course you may also achieve 
similar results by down-converting in frequency domain at the input, and a 
similar up-conversion at the output, however, using the Hilbert pair saves a 
few computations. One thing that are implied in most of the papers so far, 
is that, if you do use the Hilbert transformer, its delay must be 
compensated by a similar delay in the "I" branch. A neat description of 
this is given in: "Theory and Implementation of a Slitband Modem Using the 
TMS32010" by George Troullinos et al. SPRA013. If you ask nicely, the folks 
at TI's Literature Distribution will give it away for free. I actually have 
based my simulator on the filters that are given in this booklet. If you 
look at the coefficients that they provide in the above article, you will 
see the effect of the odd number of taps, i.e. half the coeffients are 
zero. There is, however, some concern of spurious harmonics due to 
imperfections in the transform that should ideally be removed by LPF. I'm 
not too sure how important all this would be in real applications. 




>    Two independent gaussian-distributed random variables modulate the
>I,Q components of the vector modulator for each tap.  The random numbers 
>are filtered by a low pass filter with appropriate time constant.  I am 
>guessing that a random number that is low pass filtered still has the same 
>random distribution statistics as before filtering (except for frequency 
>of course), this appears to be Ehrman's assumption.
>
>    The Doppler shift is done by a vector modulator with the variable
>being a constant-rotating phase shift, but with no random component.  The
>rotating phase generates the + or - doppler freqency offset.  The gaussian
>frequency doppler spread is caused by the first modulator (in the previous
>paragraph) since it had to contribute random phase changes.
>
>    Does this agree with your interpretation?



Yes, basically this is how I understand it too, and also from the plots that 
I have generated, looks feasible. Multiplication is distributive of course 
and you may perform the multiplications in any order. What I do is 
to first generate the complex Gaussian signal, LPF, then mix the doppler 
signal and last, mix the complex signal from the input delay line. You may 
find however, that the sample rate at the Gaussian/doppler pair are at
much lower rate than the input sampling, i.e. around the hundred SPS 
range (due to the very low frequencies generated at that point) vs. the 
input signal needs to be sampled at least twice 3 KSPS (which incidentally, 
I choose 9600 SPS). This means that you will need an interpolating filter at 
the gain tap functions else the signals there will be very ragged steps.

This brings me to another issue that the Ehrman paper is very loose on. If 
you are creating three signals that need to be combined, you need to ensure 
that they have equal power - how do you go about that? Also if the Gaussian 
generator has to be LPF'd, it will change its power, so you need to 
compensate for that when you choose your variance when generating the 
Gaussian signal. 



>    Johan, I very much appreciate the references to the various articles,
>as they speed up considerably finding and understanding the material!  
>Trying to find all the relevant articles is slow and laborious, and that's 
>one of the good things about the newsgroup - getting those important 
>references found.  I did acquire a copy of both CCIR 
>reports/recommendations you suggested, but have not read them yet.
>
>                            - Tom, N5EG



Ditto - goes without saying that I am grateful for all the participation. I 
do hope that you will consider writing all of this up some time in a 
article? 


73's

Johan, KC7WW
From FORRERJ@frl.orst.edu Mon Nov 14 10:55:53 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r74h4-0001RUC; Mon, 14 Nov 94 10:55 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA07207 for <hfsig@tapr.org>; Mon, 14 Nov 1994 01:18:17 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 14 Nov 94 8:39:16 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 14 Nov 94 8:39:04 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 14 Nov 1994 08:38:55 PST8PDT
Subject:       Re: [HFSIG:93] Bandwidth
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <7F0763671E2@frl.orst.edu>

Charles,


>I just thought you might like to know what the U.K licence says about 
>bandwidth.

>" The bandwidths of emmissions should be such as to ensure the most
>efficient utilisation of the spectrum; in general this requires that
>bandwidths be kept at the lowest values which technology and the nature of
>the service permit. Where bandwidth-expansion techniques are used, the
>minimum spectral power density consistent with efficient spectrum
>utilisation should be employed."
>
>This I take to mean, is that there is nothing precluding the use of voice
>bandwidth data modems on H.F.



Makes sense - does'nt it.



>Just got my QEX interesting article Johan.


Hope you enjoy the article. BTW, I have been meaning to talk to you about 
your table-lookup approach of doing Golay encoding/decoding. Will leave it 
for another opportunity.


> Regards Charles
> ------------------------------
> | Charles Brain (G4GUO)       |
> | Chelmsford, Essex.          |
> | E-mail chbrain@dircon.co.uk |
> | POTS +44 (0)1245 353221     |
> | FAX  +44 (0)1245 275448     |
> -------------------------------

73's

Johan, KC7WW
From Rick_Whiting@ATK.COM Mon Nov 14 16:09:32 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r79aO-0001dwC; Mon, 14 Nov 94 16:09 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id QAA13965; Mon, 14 Nov 1994 16:09:06 -0600
Message-Id: <199411142209.QAA13965@ATK.COM>
Date: 14 Nov 1994 16:09:14 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: Channelization
To: "Post hfsig TAPR" <hfsig@tapr.org>

                       Subject:                               Time:4:04 PM
  OFFICE MEMO          Channelization                         Date:11/14/94

I recall it has been suggested that the 500 Hz bandwidth proposed 
for semiautomatic unattended operation on HF (in the U.S.) originated from an
idea for "channelizing" digital operations to reduce interference.  
Regardless of the merits (or lack thereof) of establishing a limit on 
bandwidth, I wonder if channelization really would increase 
throughput on HF under the scenario described below.

Intuitively, channelization would benefit CSMA modes, e.g., AX.25.  
But it is not clear (at least to me) that channelization will necessarily 
provide the greatest throughput for the most users of a given HF 
sub-band for non-CSMA modes, particularly those employing FEC.  It 
strikes me that for protocols such as PACTOR and G-TOR it might be 
possible that more stations would pass more total data by the 
somewhat unstructured process currently employed, i.e., find the 
least noisy channel and "jump in."  It would be interesting to see the 
results of a simulation of both channelized and non-channelized 
operation given realistic band conditions and station geographic 
distribution.

Of course, if the idea is to provide the best possible throughput to a 
limited number of stations at any time, then "rationing" operation to 
(clear) channels will provide maximum available throughput for the 
lucky few.  But, laying aside the philosophical question of quality vs. 
quantity, is there any answer to the original hypothesis that non-
channelization will maximize total throughput on HF in a real world 
scenario of "many" pairs of stations attempting to communicate?




From Rick_Whiting@ATK.COM Mon Nov 14 16:28:35 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r79t2-0001UpC; Mon, 14 Nov 94 16:28 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id QAA14231; Mon, 14 Nov 1994 16:28:28 -0600
Message-Id: <199411142228.QAA14231@ATK.COM>
Date: 14 Nov 1994 16:29:34 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: Channelization
To: "Post hfsig TAPR" <hfsig@tapr.org>

                       Subject:                               Time:4:25 PM
  OFFICE MEMO          Channelization                         Date:11/14/94
Sorry, I forgot my mailings to hfsig don't append a signature.  So I hereby
confess to posting the earlier message re channelization.

73/Rick W0TN



From esilbaug@afit.af.mil Mon Nov 14 19:23:05 1994
Return-Path: <esilbaug@afit.af.mil>
Received: from stealth.afit.af.mil by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r7Cbt-0001gqC; Mon, 14 Nov 94 19:23 CST
Received: from grouse.afit.af.mil by stealth.afit.af.mil with SMTP id AA02585
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 14 Nov 1994 20:22:57 -0500
Date: Mon, 14 Nov 1994 20:22:57 -0500
From: Eric E Silbaugh <esilbaug@afit.af.mil>
Message-Id: <199411150122.AA02585@stealth.afit.af.mil>
To: hfsig@tapr.org
Subject: Re: Channel simulator math
Cc: esilbaug@afit.af.mil

Tom,

If you want more info on Hilbert transforms you might try looking
for "Discrete-time Signal Processing" by Oppenheim and Schafer.
It's one of the 'classic' DSP texts and should be in most university
libraries.  Chapter 10 is devoted entirely to Hilbert transforms.

Johan's comments on delay and coefficients are exactly correct.
Now for more gory details.  You probably also noticed that the
coeficients of the Hilbert transform have odd symetry.  In other
words, X[n] = -X[-n].  These coeficients have the same magnitude but
opposite sign.  Now, combine this with the fact that half the
coeficients are identically zero for Hilbert transforms with an odd
number of taps.  (Note that Hilbert transforms with an even number of
taps have non-zero coeficients for all taps)

Because of these nice properties we don't have to compute the response
for half the taps.  We can also take the difference of the input data
corresponding to taps with equal magnitudes and multiply this
difference once by the coeficient.  These properties reduce the number
of multiplications by a factor of 4 and halve the number of additions.
Pretty good, and we haven't even broken a sweat!

Another nice property is that these Hilbert transforms have linear
phase because of the symetric coeficients.  You get an *exact* 90
degree phase shift, plus a constant delay.  The problem is that the
magnitude response has ripples (Yes, like the potato(e) chip).

The Ehrman paper mentions having an error of less than -50 dB (I
presume they mean ripple error) in their Hilbert transform.  In my
experience this would mean a filter with ~40-60 taps, depending on the
required bandwidth.  The number of taps required increases quickly if
you need accurate response near the band edges (0 Hz and Nyquist
frequency).

Well, now that I've completely bored you...later.

Eric

    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
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This is a bit off the technical track, but I am looking for a clear, 
concise publication that explains hf communications to the lay person.
CODAN, the Australian manufacturer, used toput out such a book, but alas, 
I need something more vendor generic. 
 
At VITA, we field HF packet radio systems in developing countries, and
explaining why things do or don't work in their language is the toughest 
job of all!
 
Thanks --
Eric
 
--
Eric Rosenberg				
Volunteers In Technical Assistance	voice: +703-276-1800
1600 Wilson Blvd., Suite 500 		fax:   +703-243-1865
Arlington, VA  22209  USA 		ericr@vita.org
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After the last Dayton Hamvention, W3IWI and I drove to Baltimore and
we discussed at length some ideas I had for a "moonbounce modem". We
eventually came to the conclusion that if my scheme worked via the
moon, it should work even better over HF.

First, some background.

The basic problem is that you're operating over a dispersive, fading
channel. Received phase is essentially random, so coherence is hard to
achieve. But it turns out that you can buy back much of the loss of
noncoherent demodulation -- at the cost of increased bandwidth -- with
m-ary orthogonal signalling.

"Orthogonal" simply means that the signal states are independent of
each other.  You can build a detector that responds to one signal
state while remaining completely unaffected (in theory) by the other
states.  Plain mark/space FSK is 2-ary orthogonal signalling, assuming
the shift is large enough for the signalling rate. You can detect FSK
with two properly tuned filters, and (again in theory) the mark filter
does not respond at all to a space signal, and vice versa.

Ordinary BPSK is not orthogonal, it's antipodal. One state is the
exact opposite of the other, so instead of being independent, they
"fight" each other much like a tug-of-war contest. You use a single
detector and compare the result to a threshold. Antipodal modulation
is 3dB better than orthogonal modulation but it requires phase

coherence, which we don't have on HF.

So we're stuck with orthgonal signalling. But instead of being limited
to only two antipodal signal points, you can have as many orthogonal
signal points as you like. In m-ary orthogonal signalling, you have m
possible channel states, where m is usually a power of 2.  E.g.,
4-tone FSK is a 4-ary orthogonal modulation scheme. Each channel
symbol carries 2 bits of information in the 2^2 = 4 possible states,
assuming only one of the four tones is on at any time (otherwise you'd
just have several 2-ary systems in parallel.)

It turns out that as m approaches infinity, overall performance
asymptotically reaches the theoretical Shannon limit of -1.6dB Eb/N0,
even with noncoherent demodulation! This has been known for a long
time, but unfortunately the improvement with m is too slow to be
impractical.

Given that, here's my idea. Take a reasonable channel bandwidth, say 2
Khz since that will fit through most SSB filters. Divide this 2 Khz
into 256 frequency bins, each 7.8125 Hz wide. In order to keep the
bins independent and orthogonal, our signalling rate will be limited
to no more than 7.8125 symbols per second. But we want a slow symbol
rate anyway to minimize intersymbol interference caused by ionospheric
multipath. Also, synchronization is easier at a low symbol rate; it
may even be possible to use GPS with approximate propagation delay
figures to synchronize "open loop". Anyway, with that many bins we
could send log2(256) = 8 bits per symbol, or 62.5 bits/sec.

Although this scheme by itself is orthogonal, it isn't particularly
resistant to selective fading or narrowband interference. To improve
this I propose another layer of orthogonal coding using Walsh
functions (rows of a Hadamard matrix).

A Hadamard matrix is easily built up recursively. You start with a 1x1
matrix containing the single entry "1". Then you double each dimension
of the matrix by copying it to the right and below unchanged, and
diagonally to the lower right by inverting each bit. Here's the
recurrence relation defined using the limited graphics of ASCII:

	M(i+1) = 	M(i)	M(i)
			M(i)	~M(i)


You can keep repeating this process until you have a matrix of the
desired size. Here are the first few Hadamard matrices:

1

11
10

1111
1010
1100
1001

11111111
10101010
11001100
10011001
11110000
10100101
11000011
10010110

and so forth.

Now notice that if you take any two rows at random from a Hadamard
matrix and XOR them bitwise, you'll always get an equal number of 1's
and 0's. It's easy to see how this follows from the recursive
definition given above.

This property means that the rows (and the columns, for that matter)
of a Hademard matrix form a set of mutually orthogonal
functions. These are called Walsh functions, and have been around for
a long time. (As an aside, one clever use in the early days of
telephony was to set up wire-crossing patterns for parallel open-wire
transmission lines in order to minimize inductive crosstalk.)

Now let's say that instead of just turning on one tone (out of 256) at
a time for each transmitted symbol, we take the 8-bit symbol and index
the corresponding row from a 256x256 Hadamard matrix. The 256 bits in
that row then control whether or not the tone is turned in each of 256
frequency bins. (The amplitude of each tone is reduced to keep the
transmitter power the same.)

Each symbol still carries only 8 bits, so the energy per bit is the
same in this scheme as with the simple 1-tone-out-of-256
scheme. Moreover, for every Walsh codeword except the all-1s case,
exactly 50% of the bins are on and 50% are off, so the transmitter
power is constant. (The all 1's case could be avoided with some work
if necessary.)

So performance with and without Walsh coding should be exactly the
same over a nonfading gaussian noise channel.  But HF has both
non-gaussian (e.g., narrowband) interference and fading, often of the
frequency-selective kind. Walsh encoding should help by spreading each
symbol's energy out more evenly over the frequency channel.

You could demodulate this signal by first taking a FFT of the raw
input samples to determine the total received energy in each frequency
bin.  Then you take the FHT (Fast Hademard Transform, analogous to the
FFT) to determine which of the 256 Walsh functions was mostly likely
to have been the one that was sent.

Note that the first column in each of the Hademard matrices is a 1,
which is rather redundant.  You could omit it and save a frequency bin
(which is pretty minor). This is called a "simplex" code, as opposed
to a straight orthogonal code. But you could do much better by
augmenting the matrix with each bit inverted, doubling the number of
code words and adding a bit to each symbol. For example, if we take
the 4x4 Hademard matrix

1111
1010
1100
1001

and append to it its bit-inverse, we get

1111
1010
1100
1001
0000
0101
0011
0110

The 8 rows are now either mutually orthogonal (equal number of bit
agreements and disagreements) or antipodal (all bits disagree).

This is called a "biorthogonal" code, and in fact it's one of the
earliest error correcting codes used in spacecraft. Mariner 9 used one
(64x32, I think) at Mars in the late 1960s, before the big switch to
convolutional coding.

The only reason to prefer a simplex or orthogonal code set over a
biorthogonal code is when your channel has a polarity ambiguity (e.g.,
BPSK). You could easily determine polarity with an orthogonal or
simplex code, but not with a biorthogonal code. But we don't have that
problem here, since each "bin" is basically an on-off keyed channel without
any polarity ambiguity.

If we built a 128x128 Hademard matrix and turned it into a
biorthogonal code we could send 8-bit symbols with only 128 frequency
bins. This would let us double our symbol rate to 15.625/sec, or our
raw bit rate to 125 bits/sec. Or we could halve the transmitted
bandwidth and keep the earlier data rate (more on bandwidth issues
later).

Although this scheme should be very robust, there will be bursts of
QRM and deep flat fades too great for it to handle. We could deal with
this by adding another layer of FEC. A natural choice would be a
Reed-Solomon block code over GF(2^8). This code operates on 8-bit
symbols that matche the basic channel symbol. Paul, N9FZX has already
implemented a Reed-Solomon decoder for 8-bit symbols and has made it
freely available over the net. Although the natural block size for a
RS coder over GF(256) is a 255-byte block, you can use a smaller
blocksize if you like by just agreeing between sender and receiver
that the unused symbols are 0s and not sending them. On the other
hand, larger blocksizes are more robust for the same amount of
redundancy.

A more complicated scheme that might work better is convolutional
encoding with soft decision decoding, either Fano or Viterbi.  The
convolutional decoding itself is not a big problem (I've already
implemented and tested both decoders) but what makes it complicated is
the need to modify the Walsh function demodulator to provide soft
samples (instead of "hard" 1s and 0s) for each bit of each demodulated
symbol. There are ways to do this, but they involve a fair amount of
effort. I need to look into this.

I also need to look into the optimality of the biorthogonal
scheme. For maximum efficiency you like to have a channel code where
every possible error event is of equal probability, but the
biorthogonal code doesn't do this. (The probability of one codeword
being turned into its antipodal complement is obviously much less than
the probability of it being turned into another codeword that is
merely orthogonal to it, since the hamming distance between antipodal
codewords is twice that of the distance between two orthogonal
codewords.)  If you can't keep the codewords at equal distance, it
might help to take them into account in your upper layer FEC design.
Or it might not make a big difference, I don't know.

I'm aware that mixing a large number of discrete tones would increase
the variance of the instantaneous transmitter power. My intuition and
the central limit theorem tells me that the instantaneous envelope
power will end up looking very Gaussian. But Shannon says that
efficient modulation schemes *have* to look Gaussian, and it may turn
out that the increased coding gain of this scheme more than makes up
for any increased amplifier losses over a constant-envelope signal.

So in summary, my scheme would take a block of 8-bit data bytes, add
an appropriate number of Reed-Solomon FEC symbols, encode each symbol
into a (128,8) biorthogonal channel code, and then use each of the 128
channel bits to gate a set of 128 discrete channel tones.

Some remarks on bandwidth. The bandwidth efficiency of this scheme may
at first glance appear to be unacceptably low, especially for HF. 125
bits/sec in 2 Khz is only 0.0625 bits/sec/Hz. But the more I learn
about information theory both from the textbooks and from my work here
at Qualcomm, the more I really understand that it's counterproductive
to limit signal bandwidth. In the real world of a shared band, power
efficiency and interference resistance are FAR more important, and
these two properties are possible ONLY with extra bandwidth.

This particular modulation scheme should be incredibly robust against
both noise and QRM. It ought to be easily decodable well below the
operator's ability to even hear it. Because of its spread
spectrum-like properties, strong inband QRM can be notched out fairly
easily. Since the energy distribution of the signal is fairly flat,
after the FFT you just look for any frequency bins with energies way
above average and suppress them before the FHT step. The only limit on
the ability to suppress narrowband QRM (a CW carrier, say) then
becomes the dynamic range of the receiver and A/D converter.

So, what do people think? This stuff represents a radical departure
from the usual approach of trying to minimize congestion by cramming
as much as possible into a narrow HF channel. Because of its wide
bandwidth, we'd need STAs to test my scheme on the HF bands, and a
rule change for general use.  But the FCC's bandwidth rules are based
on intuition that happens to be completely wrong. John Costas said as
much in his classic paper "Poisson, Shannon and the Radio Amateur",
published 35 years ago, but now we actually have the technology to
pursue his suggestions!

Phil
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>time, but unfortunately the improvement with m is too slow to be
>impractical.

Uh, minor typo. That should be "too slow to be PRACTICAL by itself".

Phil
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In order to bring some levity to the heavy conversations on modulation
schemes, I think it's time I add my two cents by way of introducing
myself and expressing my interest in HF digital radio.

My name is Eric Rosenberg, my callsign is WD3Q, and I live in
Washington, DC.  I've been licensed for 20+ years, and have lived and
operated from NY, CA, SD, OH and PA before moving to DC in 1988.

In addition, for the past three years my job has kept me overseas for
long periods of time (too much, my wife says!), so I've managed to get
licenses and operate from 9L, EI, F, G, J2, VK, YJ, and ZL (and listened
from places where licenses were not available: YB and 9V).

I work for a non-government development group called VITA: Volunteers in
Technical Assistance.  Many of you have heard of us through our
satellite activities...we were the prime movers behind the Digital
Communications Experiment on UO-11 and are the license holders and
primary operators of the non-amateur activity on the UO-14 satellite. In
addition to the satellite work, we have also been involved in the design
and implementation of terrestrial radio systems, mostly in Africa and
Asia.

To date we've installed systems in Chad, Sudan (2 systems), Philippines,
Madagascar, and have assisted in the installation of systems in Lesotho,
Sierra Leone, to name a few.  The systems started out using AX.25, but
have moved to 1200 bps PSK and more rrecently PacTOR.  The distances
between stations generally range from 200 - 1000km, with the average
being 350 km.  As the MUFs start moving down, we're now revisiting what
we're putting out in the field.

Our issues have rarely been technical...it is less important what
modulation scheme is used than ability of that modem to be installed on
a wide range of radios, from the Yaesu FT-747 (probably the single most
common radio found in developing countries) to the more expensive
commercial units made by Codan, Transworld, Harris, et al. It seems that
each group we deal with has a smattering of radios, no two from the same
manufacturer or age!

The most important important issue is usability.  Can the average, not
terribly technically-minded person use this system effectively without
having to become a trained radio operator.

In the idealized world, we would like to see a system that incorporated
some from of dynamic routing and ALE (Transworld's Transcall would
suffice), user friendly software in the language of the user, and modems
using modulation schemes that would interface to the wide range of
radios we encounter.  We've also done some work incorporating embedded
controllers with the modems (this was done for a hands off, automated
satellite network in Indonesia), and that looks like the real way to go.

There's more, but these are the basics.

To get to where we're going, VITA has just started to develop some
unique applications, and hope to put up a multi-station experimental
network to test it all out.  We'll solicit you for help as it develops.

One final note...the "Volunteers" in our name refers to you.  We've had
great participation from the amateur radio community in developing and
fielding satellite and terrestrial systems.  Rick Whiting, W0TN, did our
first HF demo in Ethiopia in the mid 1980's, and we've had great help
from KD6KQ, N3EOY, EI9GL, W2JUP, HB9AQZ, SM0TER, N6ARE and others.  Norm
Sternberg and now Rick Whiting and Dave Henderson (N3EOY) teach a class
given yearly on low cost digital radio systems for the US
Telecommunications Training Institute, a government-private partnership
program that brings communications professionals from developing
countries top the US for advanced training.

I've been fascinated by the more esoteric discussions here.  Just don't
lose track of the users, please!

Eric
 
--
Eric Rosenberg				WD3Q, J20BY, YJ0AER, VK2GYA et al
Volunteers In Technical Assistance	voice: +703-276-1800
1600 Wilson Blvd., Suite 500 		fax:   +703-243-1865
Arlington, VA  22209  USA 		ericr@vita.org
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Johan writes:

> 
> Yes, basically this is how I understand it too, and also from the plots that 
> I have generated, looks feasible. Multiplication is distributive of course 
> and you may perform the multiplications in any order. What I do is 
> to first generate the complex Gaussian signal, LPF, then mix the doppler 
> signal and last, mix the complex signal from the input delay line. You may 
> find however, that the sample rate at the Gaussian/doppler pair are at
> much lower rate than the input sampling, i.e. around the hundred SPS 
> range (due to the very low frequencies generated at that point) vs. the 
> input signal needs to be sampled at least twice 3 KSPS (which incidentally, 
> I choose 9600 SPS). This means that you will need an interpolating filter at 
> the gain tap functions else the signals there will be very ragged steps.
> 
> This brings me to another issue that the Ehrman paper is very loose on. If 
> you are creating three signals that need to be combined, you need to ensure 
> that they have equal power - how do you go about that? Also if the Gaussian 
> generator has to be LPF'd, it will change its power, so you need to 
> compensate for that when you choose your variance when generating the 
> Gaussian signal. 
> 

	It would seem that we could perform the interpolation after the
multiplication and summation of all the components.  As I recall, interpolation
is really low-pass filtering,  and as convolution (FIR filter) is
associative (like multiplication), we should be able to just low-pass-filter
the final output signal,  assuming that no spurious mixing products are
generated anywhere downstream of them complex Gaussian stream.  Is this
correct, and would it save a significant amount of processing?

	Also, it does not seem intuitive that we need to actually carefully
match the received power in the three different components, since I
see no reason why all three propagation components would actually have 
exactly the same efficiency in the real world.  One of the CCIR documents
recommends testing with the three compoenents set to different relative power
and to the same relative power over about a 40 db range.

	Thanks for the informative comments from Johan and Eric.  Hopefully
this is all getting clear now.

							- Tom
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> Now let's say that instead of just turning on one tone (out of 256) at
> a time for each transmitted symbol, we take the 8-bit symbol and index
> the corresponding row from a 256x256 Hadamard matrix. The 256 bits in
> that row then control whether or not the tone is turned in each of 256
> frequency bins. (The amplitude of each tone is reduced to keep the
> transmitter power the same.)
> 
> Each symbol still carries only 8 bits, so the energy per bit is the
> same in this scheme as with the simple 1-tone-out-of-256
> scheme. Moreover, for every Walsh codeword except the all-1s case,
> exactly 50% of the bins are on and 50% are off, so the transmitter
> power is constant. (The all 1's case could be avoided with some work
> if necessary.)

...

> Phil
> 


	Phil: a question:  under this scheme, I agree that the power is
constant, however it would seem that the peak amplitude could be very
high.  Would this require a great deal of linearity in the transmitter
and receiver?

							- Tom, N5EG
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>	Phil: a question:  under this scheme, I agree that the power is
>constant, however it would seem that the peak amplitude could be very
>high.  Would this require a great deal of linearity in the transmitter
>and receiver?

Yes, it would. I address this particular point later on. I assert (without
proof) that the coding gains would make up for any losses due to having
to back off your amplifier to keep it linear.

Phil
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content-length: 1074

> At VITA, we field HF packet radio systems in developing countries, and
> explaining why things do or don't work in their language is the toughest 
> job of all!


Hi Eric

Did you see the HF product catalog of SGC Corp. ?  They have some
general description of the art of HF radio comms in there which
might be the level you are looking for. I can look up that
companys address if you like to contact them.

vy 73,
Rolf
(Swiss Disaster Relief, Telecom Group)

P.S.
We are enjoying VITA's WWW server to get the latest DHA reports...

-- 
                                --- * * * ---

Rolf Sommerhalder                             
Swiss Federal Institute of Technology (ETH)   home address:
Electronics Laboratory ETZ H60.1              c/o Rindlisbacher
Gloriastrasse 35                              Wermatswilerstrasse 96
8092 Zurich / Switzerland                     8610 Uster / Switzerland

Voice +41 1 632 76 40 (or 632 51 53)          Voice +41 1 941 59 28
Fax   +41 1 632 12 10                         AX.25 HB9CWP @ HB9OS
E-Mail rolf.sommerhalder@ife.ee.ethz.ch
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	(Smail3.1.28.1 #3) id m0r8Wqy-00015PC; Fri, 18 Nov 94 11:12 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id BAA09766 for <HFSIG@tapr.org>; Fri, 18 Nov 1994 01:50:58 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 18 Nov 94 9:11:04 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 18 Nov 94 9:10:51 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Fri, 18 Nov 1994 09:10:42 PST8PDT
Subject:       HF Simulator test results
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <851008E47FD@frl.orst.edu>

Hi All,

I have made a small test file containing test results from my efforts 
on the HF simultor. It is available for downloading via anonymous FTP from:

ucs.orst.edu /tmp/HFSIM.ZIP

This test was generated using a C program and simulating CCIR "GOOD", 
"MODERATE", "POOR" and "Flat fading" conditions. I still have to look more 
closely at intermediate results to check whether the magnitudes are OK, but 
results look like what is expected (I think?).

I would appreciate your feedback on these results.

The next step that I'm working on, is to implement the Hilbert transform, 
tapped delay lines, and complex mixers on the sound card. Since the 
Gaussian noise & doppler gain tap functions operates at a very low sample 
rate, I'm planning to let the PC generate these, and transfer the results 
over the ISA bus to the sound card for real time mixing. Perhaps I'll be 
able to listen to some real time simulations this weekend.

73's

Johan
From mcdermot@eagle.aud.alcatel.com  Fri Nov 18 11:39:30 1994
Return-Path: <mcdermot@eagle.aud.alcatel.com>
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r8XHR-0000kjC; Fri, 18 Nov 94 11:39 CST
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA10591; Fri, 18 Nov 94 11:39:23 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA03799; Fri, 18 Nov 94 11:39:21 CST
Date: Fri, 18 Nov 94 11:39:21 CST
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9411181739.AA03799@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:108] HF Simulator test results


> Hi All,
> 
> I have made a small test file containing test results from my efforts 
> on the HF simultor. It is available for downloading via anonymous FTP from:
> 
> ucs.orst.edu /tmp/HFSIM.ZIP
> 
> This test was generated using a C program and simulating CCIR "GOOD", 
> "MODERATE", "POOR" and "Flat fading" conditions. I still have to look more 
> closely at intermediate results to check whether the magnitudes are OK, but 
> results look like what is expected (I think?).
> 
> I would appreciate your feedback on these results.
> 73's
> 
> Johan
> 

	Johan:  congratulations on making so much progress on the simulator.
You are way ahead of the rest of us.  In looking through the data, I do not
understand what the data represents.  Is the numeric value a one-second
average of the amplitude from summing all the components?

							- Tom, N5EG
From shane@mdd.comm.mot.com Fri Nov 18 15:46:35 1994
Return-Path: <shane@mdd.comm.mot.com>
Received: from ftpbox.mot.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r8b8Z-00019qC; Fri, 18 Nov 94 15:46 CST
Received: from pobox.mot.com ([129.188.137.100]) by ftpbox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA24263; Fri, 18 Nov 1994 15:46:15 -0600
Received: from mdd.comm.mot.com (mdisea.mdd.comm.mot.com) by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for <hfsig@tapr.org>)
          id AA08696; Fri, 18 Nov 1994 15:46:07 -0600
Received: from daffyduck.mdd.comm.mot.com by mdd.comm.mot.com (4.1/SMI-4.1)
	id AA24206; Fri, 18 Nov 94 13:45:55 PST
Received: by daffyduck.mdd.comm.mot.com (4.1/SMI-4.1)
	id AA10734; Fri, 18 Nov 94 13:45:54 PST
Date: Fri, 18 Nov 1994 13:45:54 -0800 (PST)
From: Hugh Shane <shane@mdd.comm.mot.com>
X-Sender: shane@daffyduck
To: hfsig@tapr.org
Subject: Re: [HFSIG:101] Ideas for HF modulation and coding
In-Reply-To: <199411160022.QAA01412@servo.qualcomm.com>
Message-Id: <Pine.SUN.3.90.941118132302.1911W-100000@daffyduck>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Tue, 15 Nov 1994, Phil Karn wrote:

> 
> Some remarks on bandwidth. The bandwidth efficiency of this scheme may
> at first glance appear to be unacceptably low, especially for HF. 125
> bits/sec in 2 Khz is only 0.0625 bits/sec/Hz. But the more I learn
> about information theory both from the textbooks and from my work here
> at Qualcomm, the more I really understand that it's counterproductive
> to limit signal bandwidth. In the real world of a shared band, power
> efficiency and interference resistance are FAR more important, and
> these two properties are possible ONLY with extra bandwidth.
> 

Hmmm...

My point of reference is the work I've been doing here at Motorola. We
build RF modems which operate at 19.2 kbps over 25 kHz channels for an
efficiency of 0.768 bits/sec/Hz. The modulation scheme is 4-tone FSK with
Trellis coding and forward error correction. Of course, the Trellis coding
is overhead which reduces the effective bit rate. Does the larger
bandwidth that we have available allow us greater efficiency than that of
your proposed scheme? Do we approach some sort of limit (i.e. Shannon's)
as the system becomes more spread-spectrum like? BTW, our products operate
at VHF so we aren't too concerned about dispersion. However, we do have to
deal with fading as they were originally designed for mobile applications,
although they're finding their way into portable applications these days. 

> 
> So, what do people think? This stuff represents a radical departure
> from the usual approach of trying to minimize congestion by cramming
> as much as possible into a narrow HF channel. Because of its wide
> bandwidth, we'd need STAs to test my scheme on the HF bands, and a
> rule change for general use.  But the FCC's bandwidth rules are based
> on intuition that happens to be completely wrong. John Costas said as
> much in his classic paper "Poisson, Shannon and the Radio Amateur",
> published 35 years ago, but now we actually have the technology to
> pursue his suggestions!
> 

I'm trying to hoist it all in! I'm somewhat of a newbie to HF data so I 
don't have too many preconceptions. If a wider channel allows greater 
efficiency and better immunity to QRM then it's hard to argue against 
this on strictly technical grounds. Of course there are politics &;)

I haven't played with the sound card much yet. Is it fast enough to
perform the transforms that you mention? Maybe benchmarking these
algorithms would be a good place for me to get started? What do you say 
Johan? 

	Hugh
From Rick_Whiting@ATK.COM Fri Nov 18 17:42:55 1994
Return-Path: <Rick_Whiting@ATK.COM>
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r8cx4-000173C; Fri, 18 Nov 94 17:42 CST
Received: from gateway1 by ATK.COM (8.6.9/8.6.9)
	id RAA02651; Fri, 18 Nov 1994 17:39:39 -0600
Message-Id: <199411182339.RAA02651@ATK.COM>
Date: 18 Nov 1994 17:40:02 -0600
From: "Rick Whiting" <Rick_Whiting@ATK.COM>
Subject: Bibliography
To: "Post hfsig TAPR" <hfsig@tapr.org>, "Post Netsig TAPR" <netsig@tapr.org>

                       Subject:                               Time:5:28 PM
  OFFICE MEMO          Bibliography                           Date:11/18/94
I recommend you add the following to your bibliography list if not your
personal reference library:

"Defining, Designing, and Evaluating Digital Communication Systems," by
Bernard Sklar, IEEE Communications Magazine, Nov. 1993, pp. 92-101.

The subtitle is "A tutorial that emphasizes the subtile but straightforward
relationships we encounter when transforming from data-bits to channel-bits
to symbols to chips."  I'm not sure I agree with Dr. Sklar on the
straightforwardness of it, but I do agree it's subtile.

73 (and good reading!),
Rick, W0TN


From forrerj@ucs.orst.edu Mon Nov 21 10:52:26 1994
Return-Path: <forrerj@ucs.orst.edu>
Received: from ucs.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0r9byX-0000QjC; Mon, 21 Nov 94 10:52 CST
Received: by ucs.orst.edu; (5.65/1.1.8.2/24Sep94-1201PM)
	id AA28091; Mon, 21 Nov 1994 08:52:13 -0800
Date: Mon, 21 Nov 1994 08:52:12 -0800 (PST)
From: Johan Forrer <forrerj@ucs.orst.edu>
Subject: HF Channel simultor
To: HFSIG@tapr.org
Message-Id: <Pine.3.89.9411210801.A26685-0100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi All,

For those interested in the HF channel simulator - I have available 
results of simulation runs that I did using a C program that I wrote for 
this purpose. These results shows the signal envelope of a 1200 Hz tone under 
CCIR: GOOD, MODERATE, POOR, and Flat fading conditions. Looks reasonable 
to me, but would like your input as well.

The file is quite small, so I can mail it directly if you wish.


73's

Johan, KC7WW
From FORRERJ@frl.orst.edu Tue Nov 22 12:45:20 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rA0DK-00016rC; Tue, 22 Nov 94 12:45 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id DAA28721 for <HFSIG@tapr.org>; Tue, 22 Nov 1994 03:24:08 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 22 Nov 94 10:44:33 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 22 Nov 94 10:44:08 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 22 Nov 1994 10:44:05 PST8PDT
Subject:       HF channel simulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8B29162689D@frl.orst.edu>

Greetings,

My apologies for not responding - apparently I have a local e-mail problem 
and e-mail mail is "spotty" at best. I just retrieved the past week's 
discussion from the archive and saw Phil's interesting submission.

The simulated data file is a one second snapshot, data points are taken 100 
ticks (at 9600 sps rate) apart, and represent the envelope of a 1200 Hz 
tone (no averaging - just the absolute value of the signal at that instant). 

Later experiments confirmed how critical the relative delay between 
the three taps are. I do not see any reference in the CCIR documents about 
this, basically it only specifies one value, i.e. 0.5ms, which I take 
refers to the overall delay between the first and last tap (which 
incedentally should be relatively prime). Now - where do one put the middle 
tap? Any suggestions?    

The interpolator filter is quite important. In my case I have to upsample 
at 1:100 rate which is not too good in one big step - I prefer to apply 
the usual multirate techniques here (these are complex-valued ofcourse). As 
far as I understand it, each tap requires it own separate multirate filter 
prior to mixing with the delay-line signals. That of course is separate 
from a LPF (a real-valued filter at this point) that is contained 
in the output, i.e. after all the real components have been added. Does it 
make sense?

If you need my feedback - please e-mail me directly at the address below as 
receiving e-mail is unreliable at the moment.

73's 

Johan, KC7WW

forrerj@ucs.orst.edu
(I also am on CI$ if you prefer that route).









From FORRERJ@frl.orst.edu Tue Nov 22 13:14:52 1994
Return-Path: <FORRERJ@frl.orst.edu>
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rA0fx-0001F9C; Tue, 22 Nov 94 13:14 CST
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id DAA29026 for <HFSIG@tapr.org>; Tue, 22 Nov 1994 03:54:01 -0800
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 22 Nov 94 11:14:16 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 22 Nov 94 11:14:00 PST8PDT
From: "Johan Forrer                                                                             FL" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: HFSIG@tapr.org
Date:          Tue, 22 Nov 1994 11:13:53 PST8PDT
Subject:       HF modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8B310D736EC@frl.orst.edu>

Hi,

After just briefly browsing through Phil's post - my $0.02.

It is true that for practical reasons, non-coherent techniques makes a lot 
of sense. I just wonder though, whether we should totally disregard the 
possibility of extracting phase information with some reliability over HF 
links - this factor will play a key role of how we should trade off 
spectral efficiency and bandwidth efficiency. My question is: do we know 
enough to say yes or no at this point in time? I suspect we don't. 

If we judge from the experiences with of commercial MIL-STD-188 HF modems, 
we see that they do implement some of the things that Phil mentioned, i.e. 
orthogonal signalling in the form of 16 or 39 parallel carriers, however, 
each being phase modulated. I suspect that perhaps some tradeoff is 
possible and that is, IMHO, where we can made our contributions.      

Coding theory could do wonders when done right and perhaps should be part 
of the modulation as Phil suggest, however, I hope we do justice to 
modulation basics. I hope the simulator would help in providing some clues.

If I had my druthers, I would have opted for SS, but that is perhaps 
looking too far into the future. Or is it?

73's

Johan, KC7WW


P.S. pse e-mail me at: forrerj@ucs.orst.edu


From BobH@eworld.com Sat Nov 26 06:07:02 1994
Return-Path: <BobH@eworld.com>
Received: from hp1.online.apple.com by dptspd.sat.datapoint.com with smtp
	(Smail3.1.28.1 #3) id m0rBLu6-0000HBC; Sat, 26 Nov 94 06:06 CST
Received: by hp1.online.apple.com
	(1.38.193.5/16.2) id AA12656; Sat, 26 Nov 1994 04:06:56 -0800
From: BobH@eworld.com
X-Mailer: AOS Mailer
Sender: "BobH" <BobH@eworld.com>
Message-Id: <9411260406.tn15861@eworld.com>
To: hfsig@tapr.org
Date: Sat, 26 Nov 94 04:06:48 PST
Subject: [HFSIG] HF Channel Simulator

H.F. Channel Simulator Validation
                       Or
Making Sure The Medium Is The Message
And Not The Massage *( very droll, no? )

*With apologies to Mr. McLuhan who I don't even pretend to understand.
 
I'm new to the sig so I hope this topic hasn't been covered, or even
worse, is obvious. 
In reading over the CCIR, it is clear that the statistics of the fading
filter output are key to quality and appropriateness of the simulation. Other
functions such as Doppler offset are more straight forward and easily
measured (SNR calibration might also be a problem however).
IMHO a couple of items must be verified to show compliance or surely
any simulated performance of waveform, coding or protocol will quickly
degenerated into a challenge to the simulator's channel transfer function.
> From the CCIR "Two independent complex Gaussian ergodic random processes,
each with zero mean values and independent real and imaginary components with
equal r.m.s. values that produce Rayleigh fading..." must be generated. Any
simulator validation must show the amplitude and phase of the complex fading
envelope, for each path, to be Gaussian. This would include statistical tests
for independence (to aid diversity schemes), mean, variance and a probability
distribution histogram. Also, a simulator controller should provide the fade
statistics to document any given test run.
> Not independent but different, again from the CCIR "Each tap-gain function
has a spectrum...that in general consists of the sum of two magnetonionic
components, each of which is a Gaussian function of frequency" ( the 2 sigma
points are given as a parameter ) and later "The importance of the shape of
the tap-gain spectrum should be noted". This "double-sided smear bandwidth"
should be measured in frequency and shown to have zero mean and unit standard
deviation of accuracy over 2 or 3 sigma.
Also, in my personal wish list for a channel simulator: the CCIR suggests a
specular (non-fading) component for a ground wave which we encounter much in
MARS work. Also, a radio filter for those insisting on practicality.
Bob, wm6h
bobh@eworld.com




